gh-135893: Lazily initialize the libffi allocator in ctypes - #161844

I don't understand well how _PyOnceFlag_CallOnce() avoid reintroducing #128485. If two threads call _ctypes_alloc_callback(), the first one calls this closure_alloc_init() function and the other one calls Py_ffi_closure_alloc() which is a wrapper to ffi_closure_alloc(). At the end, the two threads call ``ffi_closure_alloc()` in parallel and we are back to #128485 issue, no?

The whole point of a once flag is that multiple threads can't call it in parallel. It's called once, per the name. When _PyOnceFlag_CallOnce is called concurrently, the other threads will wait until the winner finishes initialization. Here's the scenario:

1. Thread 1 enters _ctypes_alloc_callback.
2. Thread 2 enters the same code path.
3. Thread 1 calls _PyOnceFlag_CallOnce.
4. The once flag is unlocked, so the thread calls closure_alloc_init to initialize the libffi allocator.
5. Thread 2 calls _PyOnceFlag_CallOnce at the same time, but it sees that it's in the "locked" state, so it spins until thread 1 marks the once flag as initialized.
6. Thread 2 does not call _ctypes_alloc_callback and proceeds; the allocator has been initialized by thread 1.

Thread 2 calls _PyOnceFlag_CallOnce at the same time, but it sees that it's in the "locked" state, so it spins until thread 1 marks the once flag as initialized.

Oh, I missed that part of _PyOnceFlag_CallOnce(). I didn't know that other threads block until the function is initialized. In that case, ok, I understand that the change doesn't reintroduce the bug.